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(57) Abstract: It is an object of the invention to propose a method of transferring a file containing a certain version of an object (for 
example, a multimedia object such as an image, audio or video) from a source entity (for example, a server) to a destination entity (for 
example, a client), said version being generated at the level of the source entity as a function of the profile of the destination entity 
(screen, calculation capacity, storage ...). According to the invention a basic version of the object is described in a document written 
in a markup language (for example XML) and called basic document. One or more transformations are defined (for example into the 
XSL format). The application of a transformation to the basic document permits to generate a transformed document. An adapted 
version of the object is generated from this transformed document. Application: downloading multimedia objects via Internet, for 
example. 
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The present invention relates to a method of transferring a file containing an 
adapted version of an object, from a source entity to a destination entity. The invention also 
relates to a method of generating a file containing an adapted version of an object. 

The invention also relates to: 
5 - equipment suitable for implementing such a file generation method, 

- a transmission system suitable for implementing such a file transfer method. 

The invention also relates to programs comprising instructions for the 
execution of steps of such methods. 

The invention finally relates to: 
10 • a document written in a markup language, 

• a file formatted in boxes comprising at least a main box which contains a progressive file 
and at least a side box which contains a document written in a markup language, 
describing said progressive file, 

• and a storage medium on which such a document or such a file is stored. 

1 5 The invention finds interesting applications notably in the field of the Internet. 

Ever more pieces of equipment have access to the Internet. This is the case, for example, with 
personal computers, mobile telephones, personal digital assistants, portable computers, 
pocket computers .... These pieces of equipment have more or less limited resources (screen, 
calculation capacity, storage capacity . . .) and are connected to the Internet by links offering 

20 varying rates (radio links, wire links, optical links . . .). It is necessary for the objects to be 
transferred to be adapted as a function of the profile of the receiver. This notably permits to 
avoid the useless transmission of data which the receiver will not be able to use, and thus to 
save on the passband. 

25 

International patent application WO 99/41 734, published 19 August 1999, 
describes a graphic file organized in progressive sections and a method of selectively 
transferring such a file. This method comprises for the receiver to indicate the sections he 
needs in the progressive file. 
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This method thus implies that the receiver knows the structure of the graphic 
file and that he knows how to determine the sections to be recovered as a function of the 
resolution or the quality he wishes to obtain. 



It is notably an object of the invention to propose a method of transferring a 
file containing an adapted version of an object, which method does not need specific 
intelligence from the user. 

This object is achieved with a transfer method as described in the opening 
paragraph and characterized in that, while said source entity comprises a memory for storing 
a basic document written in a markup language and describing a basic progressive file which 
contains a basic version of said object, said method comprises: 

• a step of selecting a predefined transformation as a function of said adapted version, 

• a transformation step which comprises applying the selected transformation to said basic 
document, for generating a transformed document, 

• a step of generating a file containing said adapted version of said object based on said 
transformed document, 

• a step of transferring the generated file. 

Thus the adaptation of the version takes place on the side of the source entity. 
Therefore no particular intelligence is necessary on the side of destination entities. 

According to the invention, the source entity uses a basic document in a 
markup language, which document describes the basic progressive file which contains a basic 
version of the object to be transferred. The source entity also has one or more predefined 
transformations intended to be applied to this basic document to obtain one or more 
transformed documents. The file to be transferred is generated from the obtained transformed 
document. It contains an adapted version of the object to be transferred. This adapted version 
is different from the basic version. 

The invention notably comprises describing the objects in a markup language 
and applying the transformations to the obtained descriptions. In the following, these 
descriptions are called documents. Such a markup language permits to describe the structure 
of the basic progressive file. This means that the structure of the basic progressive file is 
visible in the obtained documents. It is thus possible to define transformations which apply to 
these documents. These transformations are expressed in a simple manner and their use 
requires little calculation. 
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By performing the transformations with the document in which the structure of 
the basic progressive file is visible, it is avoided having to decode the basic progressive files 
so as to recode them into another format The calculation load is thus limited to a 
considerable extent. 

5 Moreover, according to the invention, it is sufficient to store the basic 

document at the source entity and, in certain embodiments, the basic progressive file from 
which it comes, as well as the predefined transformations. The files to be transferred are 
generated when the need arises from the basic document by applying an adapted 
transformation. Thus it is not necessary to store them in the memory of the source entity. 
1 0 Thus the quantity of information to be stored at the level of the source entity is limited 
considerably. 

In a preferred embodiment of the invention, the basic document contains one 
or more elements delimited by tags and which may contain one or more attributes, and said 
transformation comprises suppressing one or more elements and modifying the value of one 
1 5 or more attributes and/or one or more elements. 

The predefined transformation is advantageously written in a transformation 
language which permits to define rules for transforming a document written in said markup 
language into another document written in said markup language. 

By way of example, the markup language is an XML language (extensible 
20 Markup Language) and said transformation language is an XSL language (extensible Style 
sheet language) the two being defined by the W3C consortium. 

It is another object of the invention to propose a document written in a markup 
language, using a set of given characters, and describing a binary file which contains binary 
data, markers and parameters associated to one or more markers. According to the invention, 
25 such a document: 

• comprises elements which contain contents, and/or one or more attributes, and/or one or 
more sub-elements, 

• an element being associated to each marker, the possible parameters associated to said 
marker constituting a sub-element or an attribute of said element, and the contents of one 

30 or more elements being in the form of characters of said set said characters being linked 
with said binary data. 

In a first embodiment at least part of the contents of said document 
corresponds to binary data of said binary file converted into characters of said set. 



WO 02/063494 PCT/IB02/00336 

4 

In this first embodiment the document is independent of the binary file 
because it contains itself the data of the binary file. However, the conversion of the binary 
data into characters implies a certain expansion of these data. 

In a second embodiment at least part of the contents of said document 
5 corresponds to one or more pointers to said binary data in said binary file. 

In this second embodiment the document returns to the binary file to have 
access to the data. To be of use, the document is thus to be accompanied by the binary file it 
describes. In this embodiment there is thus no expansion of data. 

It is another object of the invention to propose a particular binary file 
1 0 advantageously used for implementing a file transfer method according to the invention. 

Such a binary file is formatted into boxes and comprises at least: 

• a main box comprising a progressive file, 

• and at least an additional box which contains a document written in a markup language 
describing said progressive file. 

1 5 The additional box advantageously contains one or more transformations intended to be 
applied to said document. 

Thus all the information relating to an object is regrouped in a single file, 
which is advantageous from the point of view of file management. 

Such a file is, for example, a JPEG 2000 file. In this case the additional box is 
20 formed, for example, by the optional "XML" box defined in the JPEG 2000 standard. It may 
also be constituted by a new dedicated box. 

When said source and destination entities are remote from each other, the 
destination entity is advantageously intended to transmit to the source entity a request 
relating to an object transfer and said destination entity comprises: 
25 • a server module intended to receive and transmit requests and responses to requests, 

• a processing module intended to receive said request rel a ting to an object transfer, to find 
the basic document corresponding to said request, to transmit to said server module a 
request relating to said basic document and later to generate a file containing an adapted 
version of the object to be transferred and to transmit the generated file to the server 

30 module in view of it being transmitted to the destination entity, 

• a transformation module intended to receive said request: coming from said server 
module, which request relates to said basic document to select a transformation and to 
transmit a transformed document to said server module i n view of transmitting the 
transformed document to said processing module. 
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Moreover, the request transmitted by the destination entity permits the source 
entity to determine a profile of the destination entity, and the transformation applied by said 
transformation module is a function of said profile. For example, said request comprises a 
negotiation phase between the source entity and the destination entity to permit the source 
entity to determine the profile of the destination entity. 



Fig. 1 is a block diagram explaining the various steps of a file transfer method 
according to the invention; 
10 Fig. 2 represents an example of a transmission system according to the 

invention; 

Fig. 3 gives an example of software architecture of a server of a transmission 
system according to the invention, 

Fig. 4 describes in a diagram an example of application of a file transfer 
1 5 method according to the invention which utilizes a client-server architecture as given 
in Fig. 3, 

Fig. 5 gives a diagrammatic representation of a JPEG 2*000 code stream; and 
Fig. 6 gives a diagrammatic representation of an example of a binary file 
according to the invention. 

20 

The invention notably relates to a method o f transferring a file which contains 
a certain version of an object from a source entity to a destination entity. This transfer 
method according to the invention comprises a step of generating the version to be used for 

25 said transfer. This generation is effected based on a basic document which is written in a 

markup language and which describes a basic progressive Xlle which contains a basic version 
of said object. The step permits to generate a transformed document Finally, this transformed 
document is used for generating a file which contains another version of the object called 
adapted version. It is this file that is then transferred to the destination entity. 

30 Fig. 1 shows a block diagram summarizing the steps of a file transfer method 

according to the invention. Block Bl represents a basic progressive file F(O) corresponding 
to a certain version of an object O. Block B2 represents a basic document DOC(0) written in 
a markup language and describing the basic progressive file. Blocks B3-1 to B3-N represent 
transformations TRi(O) intended to be applied to the basic document DOC(O) to generate a 
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transformed document. A selection step S permits to select a version for the object O and also 
a transformation to be applied which is a function of the selected version. Block B4-i 
represents a transformed document DOCi(O) generated by applying the transformation 
TRi(O) to the basic document DOC(0). Finally, block B5-i represents a file F(i) generated 
5 from the transformed document DOCi(O) and which contains another version of the object 
O. Finally, at step T, the file Fi(0) is transferred to a destination entity. 

This file transfer method benefits from the progressive nature of the basic file. 
It consists of describing the syntax of this progressive basic file in a document so as to be 
able to manipulate it to generate adapted versions of the object. 

10 Such a method is advantageously used in a transmission system according to 

the invention in which the source entity and the destination entity are remote from each other. 
An example of such a transmission system i s represented in Fig. 2. This system comprises a 
source entity and at least a destination entity each having access to the Internet, which 
accesses are referred to as 4 and 5, respectively. 

15 In practice, the source entity may be spread over one or various machines. The 

spreading over various machines permits to distribute the I asks and avoid any overload at the 
level of the source entity. In the following, to simplify the expos6, it is considered that the 
source entity is accommodated in a single machine called server. 

The server 1 has a memory 1 0 and a processor assembly 12. The memory 10 

20 is, for example, in the form of a read-only memory ROM, a random access memory RAM, a 
hard disk HD and possibly a removable storage medium FD of the floppy disc type, CD- 
ROM, DVD . . . inserted into a reader whose function is to read said medium. The memory 10 
notably contains: 

• a basic progressive file F(O), 

25 • a basic document DOC(O) which describes this basic progressive file, 

• at least a transformation TRi(O) intended to be applied to the basic progressive file, 

• a set of programs P10 intended to be executed by the processor 12 for the implementation 
of a file transfer method according to the invention. 

The client equipment 2 comprises a memory 20, a processor assembly 22, a 
30 screen 23 and a user interface 24 which includes, for example, a keypad, a voice control, a 
mouse .... The memory 22 is formed, for ex ample, by the read-only memory ROM and the 
random access memory RAM. In certain ca ses the memory is also in the form of a hard disk 
HD, and/or disc-type of removable storage medium FD, CO-ROM, DVD ... inserted into a 
reader whose function is to read the data stored on said medium. The memory 22 notably 
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contains a known set of programs P20 intended to be executed by the processor 22 for 
implementing a transfer method according to the invention. 

Client equipment 2 is conventionally connected to the Internet and emits a 
request of the HTTP type containing a resource identifier (HTTP is the network protocol 
defined in RFC2616 of the IETF; the forma t of the resource indicators is defined in RFC2396 
of the IETF). The equipment which accommodates this resource responds by transferring to 
said client an HTML document which is then interpreted by the client equipment to display 
the contents of said document on the screen of the equipment (HTML is a language for 
describing content said language being currently used on the Internet and defined by the 
W3C consortium). It is common that an HTML document describes a page intended to be 
displayed on the screen, and that such a page contains links (for example in the form of 
buttons or icons) which the user may select to download a file which contains a certain 
object. When the user selects such a link, the client equipment sends a request of the HTTP 
type to ask for the transfer of said file. 

In Fig. 3 is shown an example of software architecture for the source entity 1. 
According to Fig. 3, the source entity 1 comprises three software modules: a server module 
30, a processing module 32 and a transformation module 34. The server module 30 is, for 
example, in the form of a module known by the name of APACHE (APACHE is an http 
server developed by Apache software foundation). It is configured for transmitting certain 
requests to other modules. Here the server module 30 transmits the requests relating to files 
which have a progressive format (for example, the jpeg 2000 files) to the processing module 
32, and the requests relating to files written in the mark-up language (for example, the XML 
files) to the transformation module 34. The transformation module 34 is formed, for example, 
by a module known by the name of COCOON (COCOON is an application developed in the 
JAVA language within framework of the. APACHE XML project). 

The processing module 32 notably lias for its function to find the basic 
document DOC(0) that corresponds to the progressive file format indicated in a request for 
transmission by the destination entity, and to transmit a request relating to this basic 
document DOC(O) to the server module 30. When it receives this request, the server module 
30 recognizes the mark-up format (for example XML) which is to be processed by the 
transformation module 34, and it transmits the request to the transformation module 34. 

The transformation module 34 has for its function to recover the basic 
document DOC(O) and select a transfers nation TR i(O) to be applied to the basic document 
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DOC(O) to produce a transformed document DOCi(O). It returns the transformed document 
DOCi(O) to the server module 30 which transmits same to the processing module 32. 

The processing module 32 then has for its function to generate the binary file 
Fi(O) which contains an adapted version of the object to be transferred, and to return the 
5 object to the server module 30 for it to transmit the object to the destination entity 1 . 

In Fig. 3 are shown the various steps necessary for the transfer of an adapted 
version from the source entity 1 to a destination entity 2 in the form of numbered arrows: 

• The arrow Fl represents the transmission of a request by the destination entity 2 which 
request relates to the transfer of an object. 

10 • At step F2 the server module 30 receives the request transmitted by the destination entity, 
recognizes the progressive format and transmits the request to the processing module 32, 

• At step F3 the processing module finds the basic document corresponding to the 
progressive format and launches a request hup GET relating to said document. To recover 
the basic document it applies either an implicit rule (for example, it may be decided that 

15 when the file containing the object to be transferred is called image.jp2, the associated 

XML document is called image.xml), or an explicit rule (for example, a table of 
correspondence is available which cont ains the name of the basic document associated to 
each basic progressive file). 

• At step F4 the server module 30 transmits the request relating to the basic document to 
20 the transformation module 34. 

• At step F5 the transformation module 34 recovers the basic document, selects a 
transformation and applies the selected transformation for generating a transformed 
document which it returns to the server module 30, 

• At step F6 the server module 30 transmits the transformed document returned by the 
25 transformation module 34 to the processing module 32, 

• At step F7 the processing module 32 generates a binary file which contains an adapted 
version of the object to be transferred based on the tran sformed document, and it returns 
the generated binary file to the server module 30. 

• Finally, at step F8, the server module 30 transmits the file containing the adapted version 
30 of the obj ect to the destination entity 2 . 

When the three modules are accommodated in the different machines, they all 
advantageously reach the same disc on which the data necessary for implementing a transfer 
method according to the invention are stored, that is to say, more particularly: 
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• the basic progressive files F(0), 

• the basic documents DOC(O) which describe these basic progressive files, 

• the transformations TRi(0) intended to be app! i ed to the basic progressive files. 

The processing module 32 and the transformation module 34 are, for example, 
"servlets", that is to say, applications developed in the JAVA language intended to be 
executed on a server (for example "cocoon" is a "servlet"). 

Various applications of a file tran sfer method according to the invention will 
now be described in which the client-server architecture described with reference to Fig. 3 is 
used. 

In a first example of application sliovvn in Fig. 4 the request Jl sent by the 
client 2 permits the server 1 to determine a pro (Vie PP of the client 2. In a first embodiment 
(not shown), the request Jl indicates directly the profile PP of the client 2. In a second 
embodiment shown in Fig. 4, when the server 1 receives the request Jl, it responds by 
starting a negotiation phase J2. This negotiation phase permits it to know the profile PP of the 
client 2. The server 1 (and more precisely the trans formation module 34 of the server 1) then 
chooses the transformation to be applied to the basic document DOC(O) to generate an 
appropriate file as a function of the profile PP of the client. By way of example, such a 
negotiation phase may be of the type described in RFC2295 published by the IETF in 1998 
entitled "Transparent Content Negotiation in HTTP), or in the document "Wireless 
Application Group, User Agent Profile Specification" pub! ished by the "Wireless Application 
Protocol Forum" on 10 November 1999. 

A second example of application relates to the case where the Web pages 
contain an object of low resolution (often an image) on which the client may click to 
download a complete resolution of the same object. In thai case where the transformation 
module 34 of the server 1 applies a specific trans lb rmation to generate a file that will only 
contain the data complementary to the data which the client has already used. 

A third example of application relates to the case where, on the same Web site, 
an image is proposed several times (for example ; on different pages) in different formats or 
with different resolutions. When the client navigates among the pages, the server is then 
caused to transmit various versions of the same image in succession. Each time the 
transformation module 34 applies the appropriate transformation so as to generate the desired 
version, so that it is not necessary to store in the server the various image versions which may 
be transmitted. 
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The invention is not limited to the use of a client-server architecture of the 
type described in Fig. 3. The invention also relates to a method of generating a file which 
contains an adapted version of an object, locally used by a user. For example, such a file 
generation method is advantageously used by a user who wishes to generate a small image 
based on a large image. 

The invention is applied, for example, to multimedia objects, that is to say, to 

fixed images audio or video. 

The files which contain a version of this type of object are for example, files 
of the JPEG 2000 format, of the GIF format or of the MPEG4 format. In the following of the 
description they are qualified as binary files because, physically, they appear as an arbitrary 
bit sequence. 

A progressive file is a file which is organized so that by recovering only part 
of the file one obtains a degraded version of the object. There are various types of 
progressiveness: recovering more data may, for example, permit to improve the quality of the 
signal, to obtain larger sizes of images, to obtain a color image instead of a gray-level image, 
to increase the frame frequency of a video .... For example, the JPEG 2000 files are 
progressive files. 

Certain formats of image files permit to include in an image file a "thumbnail" 
which is a degraded version (often a smaller versi on) of the image contained in the image 
file. This is, for example, the case with Exif 2.1 files ("Digital Still Camera Image File 
Format Standard; Exchangeable image file format for Digital Still Cameras: Exif, Version 
2.1", 12 June 1998, Japan Electronic Industry Development Association (JEIDA)). This type 
of files also constitute progressive files in the sense of the invention. The basic document 
associated to this type of file will describe, on the one hand, the thumbnail and on the other 
hand the image. For example, the transformation will be defined which will permit to extract 
the part relating to the thumbnail from the basic document, so that a transformed document 
describing Ihe thumbnail is generated, said transfored document being intended to be used foi 
generating a binary file containing said thumbnail 

In a general manner a markup language is understood to mean a language 
which utilizes tags and defines rules of use of these t ags to describe the syntax of a data set. 
Such a language thus permits to structure a data set and separate the structure of the data set 
from its contents. 

XML is atypical example of such a markup language. XML offers the 
advantage of largely being used in the Internet world. Another advantage of XML is that it 



WO 02/063494 PCT/IB02/00336 

11 

offers a certain number of tools, notably a tool called XSLT which permits to define 
transformations which can be applied to XML documents. The definition of a transformation 
is made via an XSLT style sheet In an XSLT transformation, an XSLT processor reads an 
XML document and an XSLT style sheet to generate another document, for example, an 
XML document. XML and XSLT thus lend themselves particularly well to the 
implementation of the invention. 

In the following of the description and to give concrete examples, the XML 
language is used for generating documents which describe files of the JPEG 2000 format. 
This is not restrictive. Another type of markup language and other progressive file formats 
may be used. 

The JPEG 2000 standard is described in the document ISO/IEC FCD15444-1 
entitled "JPEG 2000 Final Draft International Standard". 

The main JPEG 2000 coding steps are the following: 

a) an optional transformation step of the input image to obtain a representation of the image 
in the space Y-Cr-Cb, where Y is the luminance component, Cr the chrominance 
component red and Cb the chrominance component biue; 

b) a wavelet transformation step of the image co mponen t:s ; 

c) a quantification step of the obtained coefficients; 

d) a coding step; 

e) a step of inserting data obtained in a bit stream accordi ng to a certain progressiveness 
scheme. 

When the image to be coded is very large, a preliminary step permits to divide 
it into various tiles which are coded independent ! y of each other. In the following of the 
description, for simplicity of the expose, a limitai ion will be made to the case where the 
image comprises a single tile. This is not restrictive. 

JPEG 2000 provides the use of four elementary progressiveness schemes: via 
resolution, quality, spatial location and component. JPEG 2000 also proposes five 
combinations of these elementary schemes. Each progressiveness scheme corresponds to a 
specific way of ordering the data in the bit stream 

The bit stream comprises packet headers and packets which contain the useful 
data resulting from the coding. Each packet of useful dala corresponds to a component (i), a 
layer Q), a level of resolution (k) and a partition location (rn). The bit stream is constructed 
by using four loops. The order of the loops determines the progressiveness scheme used. 
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For a bit stream having a progressiveness via components, the order of the 
four loops is, for example, the following: for each component, for each resolution, for each 
layer, for each partition location => writing of the packet in die bit stream. For a bit stream 
having a resolution progressiveness, the order of the four loops is, for example, the 
5 following: for each resolution, for each component, for each layer, for each partition location 
=> writing of the packet in the bit stream. In the following of the description these two 
examples of progressiveness will be limited to, but the inve ntion is applicable to any type of 
progressiveness. 

In accordance with the JPEG 2000 terminology, all the information relating to 

10 an image is combined in a code stream. The code stream comprises a main header, one or 
more tile part headers each followed by a bit stream and it is ended by an end marker. The 
main header and the tile part headers are organized in markers and marker segments. Finally, 
the code stream itself is contained in a binary file. 

Fig. 5 represents the structure of an example of a JPEG 2000 code stream. 

1 5 This code stream CS starts with a main header 1 00 which contains a marker SOC (Start Of 
Code stream) followed by marker segments SIZ (image and tile SIZe), COD (COding style 
Default) and QCD (Quantization Default). It then compri ses a tile part header 110 which 
contains a marker segment SOT (Start Of Tile part) followed by a marker SOD (Start Of 
Data). It finally comprises a bit stream 120 in the form of various packets optionally preceded 

20 by markers SOP (Start Of Packet) which are used to mark the start of the packets. And it is 
ended by an end marker EOC (End Of Code stream). The names used here are those of the 
JPEG 2000 Recommendation. Other optional markers are defined in the JPEG 2000 
Recommendation. More particularly, a marker is a two-octet code. And a marker segment 
comprises a marker and parameters associated to the marker. 

25 The XML language bases will now be explained. This language is described in 

the Recommendation of the W3C consortium entitled REC-xml-1 99802 10 published on 10 
February 1998. 

From a physical point of view an XML document may comprise entities that 
can be analyzed and entities that cannot. An entity that can be analyzed contains text, that is 
30 to say, a sequence of characters belonging to a predefined character assembly, which 

represent tags or textual data. An entity that cannot be analyzed may contain something else 
than text or a text which is not an XM L text. 

From a point of view of logics, an XML document contains one or more 
elements whose limits are marked by an opening lag and a closing tag. Elements may be 
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interleaving with each other. Each element is identified by a name. It may contain contents. It 
is possible to associate a set of attribute specifications to it. Each attribute specification 
comprises a name and a value. No attribute name can appear various times in the same start 
tag. 

A method of structuring a JPEG 2000 code stream with the XML language 
will now be described. 

In this example a choice is made to create an XML element for each marker 
segment of the JPEG 2000 file by applying the following rules: 

• the element is named after the three-letter code of the marker, 

• the length of the marker, its value and possibly the ot her parameters associated with the 
marker are defined as attributes of the element, 

• when a parameter or a parameter group is repeated, a sub-element is created instead of an 
attribute, because the XML language does not permit to have more than one attributes 
with the same name in a same start tag (this is the case, for example, with the marker 
segment SIZ which is terminated by a group of three parameters Ssiz, XRsiz and YRsiz 
repeated for each of the components of the image), 

• the packets of the bit stream are included in the document in the form of the contents of 
an element. 

But as the bit stream is composed of purely binary data, it is not possible to 
directly include it in an XML document (which tolerates only certain well-defined 
characters). 

In a first embodiment, the bit stream is converted into characters. For this 
purpose, a coding method is advantageously used which is known by the name of "base 64" 
and described in paragraph 6.8 of the document RFC2045 published by the IETF. This 
method comprises splitting up the bit stream into gr oups of 6 bits and associating to each 
group of 6 bits a character from a character alphabet. This method thus offers the drawback 
that it brings about an expansion of the data by 33%. 

In a second embodiment, in lieu of converting the bit stream into characters to 
be inserted into the XML document, pointers are introduced in the XML documents, which 
point at the areas of the basic file which contain the binary data. In this embodiment the XML 
document becomes dependent on the basic file. 

In annex 1 is given by way of non-limiting example, an XML document which 
describes the JPEG 2000 code stream represented in Fig. 5 for a progression diagram via 
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components. In this example the contents of the packets have been truncated so as to occupy 
only a single line. 

Two examples will now be given of transformations which may be applied to 
an XML document to generate a transformed XML document which describes an ameliorated 
5 version of the image. A transformation generally comprises a suppression of certain of the 
elements of the basic XML document and a modification of the value of certain attributes 
and/or of certain elements so as to maintain the coherence of the code stream set 

A first example of transformation is a transformation which can be applied to 
images coded with a component progressiveness which permits to pass from a color image to 
10 a gray-level image. Such a transformation comprises the suppression of the packets of the bit 
stream that correspond to chrominance components. For this purpose this transformation 
comprises the following steps: 

• suppression of the elements SOP which correspon d to the chrominance packets, 

• suppression of the elements which contain the attributes Ssiz, XRsiz and YRsiz which 
1 5 relate to the chrominance components, 

• modification of the attribute Csiz of the element SIZ wh ich indicates the number of 
components (old value 3 => new value 1), 

• modification of the attribute MarkSegLen of the element SIZ which indicates the size of 
the marker segment SIZ (old value 38+3.3 = 47 => new value 38+3.1 = 41). 

20 Such a transformation is advantageously defined in an XSL-style sheet. In 

annex 2, by way of non-limiting example, an XSL-style sheet is given intended to be applied 
to the XML document described in annex 1 . 

A second example of transformation is a transformation which may be applied 
to images progressively coded via resolutions, which permits to change from a large size 

25 image to a smaller size image. Such a transformation uses an input parameter Nresout which 
defines the number of resolutions to be obtained. The trans f ormation comprises a suppression 
of the packets of the bit stream which correspond to resolutions higher than Nresout. For this 
purpose, the transformation comprises the following steps: 

• suppression of the elements SOP corresponding to (Nres-Nresout). Ncomp.Nlayers last 
30 packets of the bit stream, where Nres, Ncomp and N layers are the numbers of resolutions, 

.:• components and layers, respectively, used in the progressive basic file, 

• modification of the attributes of the element SIZ which relate to the size of the image: 
division of the value contained in the attributes Xsiz, XTsiz, Ysiz and YTsiz by 2 N(res " 

Nresout) 
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. modification of the attribute of the el ement COD whi c h relates to the number of 

decomposition levels (nDecompLevel = Nresout), 
. as a function of the quantification style indicated by the attribute Sqcd of the element 

QCD, suppression of the last elements SPqcd, 
• making the attribute markSegLen to comply with the element QCD. 

The two examples of transformation wh ich have just been described are not 
limitative. The invention may be applied to other types of transformations. For example, 
transformations may also be defined which may be applied to images progressively coded via 
layers, which permits to obtain various signal-to-noise ratios. 

Fig. 6 represents an example of a binary file in the JPEG 2000 format 
according to the invention. According to Fig. 6 a binary file FF of the JPEG 2000 format 
comprises a main box BX1 which contains a code stream CS which constitutes a basic 
progressive file in the sense of the present invention. It also comprises an additional box BX2 
which contains an XML document referred to as DOC. The document DOC describes the 
code stream CS. The additional box B2 can also contain a transformation XSL referred to as 
TR intended to be applied to the document DOC. 
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<?xml version""!.. 0" ?> 
<Codestream> 

<MainHeader> 

<SOC markSegLen="-l" markerCodeStr=" f f 4f '> 

</soc> 

<SIZ Csiz="3" RsizStr="JPEG 2000 - Part I" XOsiz="0" XTOsiz="0" XTsiz="515" 
Xsiz«="515" YOsiz="0" YTOsizs= M 0" YTsiz="Sl2" Ysiz="512" markSegLen="47" 
markerCodeStr= n ff51"> 

<Comp_siz Ssiz="7" XRsiz«"l" YRsiz-"l"> 
</Comp_siz> 

<Comp_siz Ssiz="7" XRsiz="l" YRsiz="l"> 
</Comp_siz> 

<Comp_siz Ssiz="7" XRsiz= n l" YRsiz= ,, l ,, > 
</Comp_siz> 
</SIZ> 

<COD codeBlockHeightExp="4" codeBlockWidthE>;?-"4" ephUsed=" false" 
markSegLen*="12" markerCodeStr=*"f f 52" mct-n" nDecoiapLevel="5" 
numLayers="l" optByPass-" false" optErTerra?-" false" optRegTermp" false" 
opt:ResetMQ=" false" optSegMarkers-" false" optVertStrCausal«"f alse" 
precinctPartitionIsOsed=" false" progTy P e="4" progTypeStr=" Component" 
sopUsed="true" wavTrans="0" wavTransStr="9-7"> 

</COD> 

<QCD Sqcd="2" markSegLen-"35" markerCodeStr«"f f 5c" nGuardBits="2"> 
<SPqcd spqcd_val«="284 4 0"> 
</SPqcd> 

<SPqcd spqcd_val J ="28394 "> 
</SPqcd> 

<SPqcd spqcd_val="28394"> 
</SPqcd> 

<SPqcd spqcd_val*="28348"> 
</SPqcd> 

<SPqcd spqcd_val«="263 68"> 
</SPqcd> 

<SPqcd spqcd_val~"26368"> 
</SPqcd> 

<SPqcd spqcd_val="26333"> 
</SPqcd> 

<SPqcd spqcd_val="243 96"> 
</SPqcd> 

<SPqcd spqcd_val="243 9 6"> 
</SPqcd> 

<SPqcd spqcd_val="24420*> 
</SPqcd> 

<SPqcd spqcd_val="184 35"> 
</SPqcd> 

<SPqcd spqcd_val«"184 35"> 
</SPqcd> 

<SPqcd spqcd_val^"18501"> 
</SPqcd> 

<SPqcd spqcd_val«"204 3 4 "> 
</SPqcd> 

<SPqcd spqcd_val="204 3 4 "> 
</SPqcd> 

<SPqcd spqcd_yal="20321"> 
</SPqcd> 
</QCD> 

< /MainHeader> , , 
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ANNEX 1 page 2 

<TilePartHeader> 

<SOT lsot="0" Psot*="32722" TNsot="l" TPsot="0" markSegLen^'lO" 

mar ke rCode Str="ff90"> 
</SOT> 

<SOD markSegLen="-l" markerCodeStr= M f f 93 "> 
</SOD> 

<SOP Lsop^O" Nsop="0 w roarkSegLen="4" markerCodeStr="f f 91"> 

zokxf jAav/OeNhOKCgQ^ 
</SOP> 

<SOP Lsop="0 rt Nsop» ,, l w markSegLen= ,, 4" markerCodeStr="f f 91"> 

vih3XvSqAxdN7qp7Aubt+hlA5Iai7DMKpOQYslJGcF+kax9m 
</SOP> 

<SOP Lsop="0" Nsop="2 n markSegLen="4" markerCodeStr= M f f 91"> 

ion5 YDUL4 Hqwa I z DAg== 
</SOP> 

<SOP Lsop="0" Nsop="3" markSegLen="4" markerCodeStr="f f 91"> 

v5HtMkNwzwEIhKL7bEcpU5ZrplIfzrl8kZkNLcralCv.'=== 
</SOP> 

<SOP Lsop="0 M Nsop=M" markSegLen="4 " markerCodeStr="f f 91"> 

o3a7iCv0mlV/xPkZz6Ks7HXbJYUyLNnyi8JhjOOeYgvi 
</SOP> 

<SOP Lsop= M 0" Nsop="5" markSegLen= , M " marke;:CodeStr= ,, f f 91"> 

4opHeHv9L+qiu/UplNkyVlPIV?oc3umf k!4 26eDl£Kh7GtEvbkCMaknWAcYYxjmf 
</SOP> 

<SOP Lsop="0" Nsop= M 6 M mark3egLen="'j " markerCodeStr*= n f f 91"> 

EnE F 6 2 yGwcRt Y 2 ehQYEpuQ- - 
</SOP> 

<SOP Lsop=*"0" Nsop= w 7" markSegLen='M " markerCodeStr»"f f 9J. M > 

ldWatY7LLQ== 
</SOP> 

<SOP Lsop= M 0" Nsop= M 8" markSegLen="4" inarkerCodeStr="f f 91 n > 

b3qu8Ev6TqqoK4IItml9ClfijOS\ri / 2qqIM^vwd7eSOOhyp5bIStPlwMOsB6i2b/jSJMo80vg- 
</SOP> 

OOP Lsop="0 M Nsop="9" markSegLen="4 " markerCodeStr="f f 91"> 

83mg5+Jv95wRIRM61swVVYBfIw7 e Aob 2 BN r rnB s C 3. X r T j vzGFLS rY lBCyAn8 C S 
</SOP> 

<SOP Lsop=*"0" Nsop="10" marI:S3gLen="4" markerCodeStr="f f 91"> 

7psE6f JW2/G3ohpvNaT+ovEFacTFj+H-9sdVip0Xv;r.n , n25oWq2yZYNh+DWr3T7H+V 
</SOP> 

<SOP Lsop="0 M Nsop="lX" markSegLen= r M" markerCodeStr="£ f 91"> 

XaILyXsuXvRI+C4p 
</SOP> 

<SOP Lsop="0" Nsop="12" markSegLen="4" markerCodeStr-"f f 91"> 

W6qLBsuVSFjQRnGVfO27J97datiNDa0Yj] J ttBepCvrjXQu71TWIWBzRRRQmPgpPBg— 
</SOP> 

<SOP l,sop="0" Nsop="13" iaarkSegLen= M 4" inar kc-.::CodeStr="f £ 91 M > 

3 s +E CWT / Z j kqN aHDcQ— 
</SOP> 

<SOP Lsop="0" Nsop="14 w marl:SegLen« M 4" mar korCodeStr="£f 91 M > 

+eQE2Ek04vydGK++tx9kkp j ZL6Tei R2r.c4crNQ4 zllDurQg— 
</S0P> 

<SOP Lsop="0" Nsop="15" markSegI,er.~"a" markerCodeStr- n f f 91"> 

lcQa4O/p/tH7FOjY0f jYef zcUtdrynh7PJ>A-hBft.KTu0F6Y5qXhDlD4G2uBd/a7 
uw4 9QaaPKt f Jb8XiaVpXVqBW 9 LwoqQ=— 

</SOP> 

<SOP Lsop="0" N3op="16" mark3egLen»"4" markerCodeStr=' , f f 91 M > 

Zj Jalwvkx0SiIQUOsc/RkjO4v:qeX6qg3miqkFQ^ == 
</SOP> 

<SOP Lsop="0" Nsop= ,, 17" raarkSegLen= M 4" markerCodeStr="f f 91 "> 

</S0P> 
</TilePartHeader> 

<EOC markSegLen="-l M markerCcdc3tr- ,, i:fd9"> 
</EOC> 

< /Codes treain> 
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ANNEX 2 page 1 

<?xml version="1.0"?> 



Remove color components : 

For this, this stylesheet performs the following transformation: 

- check that SOP markers are used 

- check progression type 

- check that multiple component transform is used 

- check that nCompOut <« Cs iz 

- replace the Csiz attribute value by the wanted value (nCompOut) 

- delete Compos iz elements accordingly 

- update markSegLen value accordingly 

- delete SOP elements accordingly 

Input parameter : nCompOut, default value = 1 



<xsl : stylesheet xmlns :xsl="http: //www. w3 . org/1 99 9/XSL/Transf orra" version«="l . 0 M > 
<xsl : import href="tplCheckSOPU: *ed . xsl" /> 
<xsl: output method-"xml" indent^'yes" /> 

<! — Parameter: number of output components - Default value — 1 — > 
<xs 1 : pa r am name= " nC ompOut n >1< / x s 1 : pa r a n i > 

<1 — Match all: default template — > 
<xsl: template name="tplAll" match=-"@* i node { ) M > 
<xsl : copy> 

<xsl : apply-templates select="0* |node() "/> 
</xsl:copy> 
</xsl : template> 

<! — Match COD/@sopUsed - Overrides tplAll --> 

<xsl: template name="tplSopUsed" match- M //COD/@sopUsed" priority-"l"> 

<! — Check /COD/sopUsed value — > 

<xsl : call-template name- n tplChec):SOHJsed ,, /> 
</xsl : template> 

<! — Match COD - Overrides tplAll — > 

<xsl: template name="tplCOD" match*="COD" priority« ,, l"> 

<! — Check progType value --> 
<xsl:if test«"@progType!=4 M > 

<xsl :message terminate-*" yes "> 

Error: progression type is <xsl : value-of select="0progType" /> 
Should be 4 (progression by color component) 
</xsl:message> 
</xsl:if> 

<! — Check met value — > 

<xsl:if test="@mct=0 and //SIS/eCsi?.--=3 ,, > 
<xsl :message> 

Warning: no multi-comi .;nent trahsf. was applied to input image. 
If input was RGB, outp.it: will be the Sod component. 
</xsl :message> 
</xsl:if> 

<! — Copy COD — > 
<xsl :copy> 

<xsl : apply-templates select" "G * " /> 

<! — Set met value to 0 --> 

<xsl : attribute name="mct ">0< /xsl : a ttribv. te> 
</xsl:copy> 

</xsl : template> 
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<i__ Match SIZ - Overrides tplAll — > 

<xsl: template name="tplSIZ" match="SIZ" priority- 1 > 

<!-- Check nCompOut value : should be <= Csiz — > 
<xsl:if test="({$nCompOut > 0Csiz) or U'.nCompOut < 1)) > 
<xsl: message terminates" yes "> r , _ . 

Error: number of output color components should be &gt,- 1 
and Sit; <xsl : value-of selec t="0Csiz" /> . Exit... 
</xsl:message> 
</xsl: if> 



<xsl:copy> 

<! — Copy attributes — > 
<xsl : apply- templates select=" 0 • ' " /> 

<i — Update Csiz value — > 
<xsl: attribute name«="Csiz"> 

<xsl: value-of select-"$nCompOut ,, /> 
</xsl : attribute> 

<l — Update markSegLen value accordingly > 
<xsl: attribute name="markSegL*n"> 

<xsl:value-of select="3S + 3 * $nConipOut n /> 
</xsl : attribute> 

<! — Copy only relevant Comp_si?. elements > . . ,„/^ 

<xsl:apply-templates select="Comp„si z [ pos it ion ( ) <« $nCompOut ] /> 

</xsl:copy> 
</xsl : template> 

<i_- Match TilePartHeader - Overrides tplAll — -> 

<xsl: template name- " t P IT ile Part Header- M tch- "TilePartHeader" priorxty--l' > 

<! — Calculate number of output packets > 
<xsl: variable name="nSOPOut"> 

<xsl : value-of select= . „ . 

" <//COD/@nDecompLevel + 1) * //COD/0numLayors * $nCompOut /> 

</xsl : variable> 

<xsl: copy> 

<! — Copy attributes — > 

<xsl:apply-templates select-" 8+ i SOT 1 SCD"/> 

<l - ^,^1?^^^'^^^ «lt,- $ nSOPOut 3 .V> 
<xsl:message> 

Initial number of. SOP : <xsl : value-of 

select-" count (SOP) "/> , . . 

S Output number of SOP : <>:sl : value-of 

select«"$nSOPOut M /> 

</xsl:message> 

</xsl:copy> 
</xsl : template> 

</xsl : stylesheet> 
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<?xml version="l. 0"?> 
< i — 

This stylesheet performs the following transformation: 
- check than "sopOsed" attribute of "COD" element is set to yes, 
otherwise, exit 

— > 

<xsl: stylesheet xmlns : xal-"http: //www. w3 . org/ 1999 /XSL /Trans form" version="l . 0»> 

<! — Template tplCheckSOPUsed — > 
<xsl : template name=" tplCheckSOPUsed " > 

<xsl: variable name="sopUsed"> 

<xsl:value-of select="//COD/G sopOsed" /> 
</xsl:variable> 

<xsl : if test-" $ sopUsed ! = 1 true ■ "> 
<xsl -.message terminate«="yes"> 

Error: SOP markers are nol: used in this codetsream. 
Cannot process. Exit... 
</xsl:message> 
</xsl:if> 

<xsl:copy/> 

</xsl : tempi at e> 

</xsl:stylesheet> 
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CLAIMS: 



1 . A method of transferring a file containing an adapted version of an object (O) 
from a source entity (1) to a destination entity (2), characterized in that, while said source 
entity comprises a memory (10) for storing a basic document (DOC(0)) written in a markup 
language and describing a basic progressive file (F(0),CS) which contains a basic version of 

5 said object, said method comprises: 

• a step of selecting a predefined transformation (Tri(0)) as a function of said adapted 
version, 

• a transformation step which comprises applying the selected transformation to said basic 
document, to generate a transformed document (DOCi(0)), 

10 • a step of generating a file (Fi(0)) containing said adapted version of said object based on 
said transformed document, 

• a step of transferring the generated file. 

2. A method of generating a file which contains an adapted version of an object 
1 5 from a basic document written in a markup language and describing a basic progressive file 

which contains a basic version of said object, said method comprising a transformation step 
of generating a transformed document by applying to the basic document a predefined 
transformation which is a function of said adapted version, the file containing said adapted 
version being generated from the transformed document. 



20 
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3. A method of generating a file as claimed in claim 2, characterized in that as 
said basic document contains one or more elements delimited by tags and which may contain 
one or more attributes, said transformation comprises suppressing one or more elements and 
modifying the value of one or more attributes and/or of one or more elements. 

4. A method of generating a file as clai med in claim 2, characterized in that the 
predefined transformation is written in a transformation language which permits to define 
rules for transforming a document written in said markup language into another document 
written in said markup language. 
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5. Electronic equipment comprising a memory which contains a document 
written in a markup language and which describes a basic progressive file, and means for 
implementing a method of generating a file as claimed in claim 2. 

5 

6. A transmission system comprising at least a source entity and one or more 
destination entities, said entities being intended for implementing a method of generating a 
file as claimed in claim 1 . 

10 7. A document written in a markup language which uses a set of predetermined 

characters, said document comprising elements which contain contents, and/or one or more 
attributes and/or one or more sub-elements, and said document describing a binary file which 
contains binary data, markers and parameters associated to one or more markers, 
characterized in that in said document an element is associated to each marker, while possible 

1 5 parameters associated to said marker form a sub-clement or an attribute of said element, the 
contents of one or more elements being formed by characters of said set said characters being 
linked with said binary data. 

8. A file formatted in boxes, comprising at least: 
20 • a main box comprising a progressive file, 

• and at least an additional box containing a document w ritten in a markup language and 
which describes said progressive file. 

9. A program comprising instructions for the execution of the steps of the file 
25 transfer method as claimed in claim 1 when said program is executed by a processor. 

10. A program comprising instructions for the execution of the steps of the 
method of generating a file as claimed in claim 2 when sain program is executed by a 
processor. 



30 



11. A method of transferring a file as c! ai med i n claim 1 , characterized in that as 

said source entity (1) and destination entity (2) are remote from each other, the destination 
entity is intended to transmit to the source entity a request relating to an object transfer (Fl) 
and said destination entity comprises: 
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• a server module (30) intended to receive and transmit requests and responses to requests, 

• a processing module (32) intended to receive said request relating to an object transfer 
(F2), to find the basic document corresponding to said request, to transmit to said server 
module a request relating to said basic document (F3) and later (F7) to generate a file 

5 containing an adapted version of the object to be transferred and to transmit the generated 

file to the server module in view of it being transmitted to the destination entity (F8), 

• a transformation module (34) intended to receive said request coming from said server 
module, which request relates to said basic document (F4) to select a transformation and 
to transmit a transformed document to said server module (F5) in view of transmitting the 

1 0 transformed document to said processing mod u le (F6). 

12. A method of transferring a file as claimed in claim 1, characterized in that said 
request permits the source entity to determine a profile (PI 1 ) of the destination entity, and the 
transformation (Tri(O)) applied by said transformation module is a function of said profile 

15 (PP). ' 

13. A method of transferring a. file as claimed in claim 12, characterized in that 
said request (Fl) comprises a negotiation phase (S2) between the source entity (1) and the 
destination entity (2) to permit the source entity to determine the profile (PP) of the 

20 destination entity. 
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